ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group94b.txt/000045_icon-group-sender _Mon Sep 5 19:49:16 1994.msg

Internet Message Format | 1995-02-09 | 4KB

Received: by cheltenham.cs.arizona.edu; Mon, 5 Sep 1994 17:54:03 MST
To: [e-mail]
Date: 5 Sep 1994 19:49:16 -0400
From: [e-mail] (Nick Williams)
Message-Id: <34gaps$[e-mail]>
Organization: Internet Online Services
Sender: [e-mail]
References: <[e-mail]>, <347vun$[e-mail]>, <[e-mail]>
Subject: Re: Icon - still alive??
Errors-To: [e-mail]

In article <[e-mail]>,
Richard L. Goerwitz <[e-mail]> wrote:
>In article <347vun$[e-mail]> [e-mail] (Nick Williams) writes:

>>What was Icon intended for then?

>Your opinion is a valid one, and shared by others.  I just don't happen
>to agree.  We are going in circles here, in a sense, because my answer
>to what you are saying now is the same answer I gave before:  If you need
>system-dependent features, improve Icon's access to facilities that deal
>with them.  To extend Icon here and there to make it more PERL-like or
>more C-like will fritter away the language.

I didn't say that Icon itself should be extended, just that system
specific stuff should be put into libraries. I can add them myself
(through loadfunc() if you wish), but such system specific function
libraries should be standard IMHO. It would just make Icon that much
more useful; if people were then to use it in ways you deplore, so what?

>  No recompilation
>of the Icon source is needed.  I like this.  There are even some exam-
>ples in the new documentation for Icon 9.0.

It's nice yes (though recompilation is necessary on systems that do not
support dynamic loading). Note that the C-Icon calling interface has
been removed (you can call C from Icon, but not Icon from C).

>  In theory it is
>nice to have a language be all things to all people.  But once a lang-
>uage comits to this philosophy, it's hard to know when to stop.  And the
>result can be ugly and messy.

True, and Ada is a perfect example, but as someone else pointed out Icon
would be very well suited for developing a WWW browser; but of course,
the lack of a standard interface to system specific stuff complicates
matters. I can develop my sys specific library, so can you, but a
standard would be best. You're limiting Icon's potential! :)

>Here's a prime example.  Creation of a new process in Unix is not atomic.
>You have to copy the current process, then overlay it.  This is pretty
>system dependent.

Not! fork() does not necessarily involve copying, particularly if you
exec() soon after the fork(). Every Unix system works like this, and
others are similar. Just because these are so system specific doesn't
mean you can't use them, just that you should be careful about using
them when you intend to write portable code (portable to non-Unix like
systems that is).

>  You mentioned setenv() above.  I don't believe that
>the Mac has environment variables per se.  Getenv() is marginally useful
>for passing information about the environment to Icon (e.g. if you want
>to know what TERM type you have under Unix).

>  But then I
>could see how almost every platform-specific facility might be useful
>at one time or another.  That doesn't mean I want to see them as part
>of the core Icon language definition.

Ah, but you see, sometimes there's no portable way to do a certain task,
a small part of a large project for which Icon is well suited; are we to
forget about using Icon then, just because one procedure needs to use
setenv() or fork(), or exec() or...?

>To back off a moment, let me just repeat that your opinion is perfectly
>reasonable, and I'm sure many others share it.  There's another side,
>though, and that's the one I happen to be on.

I just don't see what is wrong with standardizing an Icon library of
system specific functions. If standard would be welcome I would
volunteer time to write/implement it.

>--
>
>   -Richard L. Goerwitz              [e-mail]
>   [e-mail]          rutgers!oddjob!ellis!goer

Nick